params: Config2 #32224

fjl · 2025-07-16T13:03:29Z

This is a refactoring of the fork configuration system. The design goals for this change are as follows:

Forks
- Eth mainnet forks and their progression should be defined in one place only. At the moment, adding a new fork requires lots of additions in package params, defining new methods, updating validation rules, etc. I wanted
  to make this simpler, so that ideally a new enum value has to be added and that's it.
- I want to enable defining forks in other packages. For certain changes, such as RIP implementations, a fork should be more like a feature flag that can be enabled.
- For eth mainnet, forks are ordered by their activation, but a key insight from this change is that defining a total order among forks is not possible generally. So in the new system, we have to explicitly define dependencies between forks, establishing partial order. Our reliance on total fork order needs to be lessened across the codebase, to ensure we only depend on the partial ordering as defined.
- Some forks are optional. This includes difficulty adjustment forks from before the merge, and the new BPO forks. The defined dependencies reflect this.
- Finally, it should be possible to make one fork auto-activate another. This is to handle certain special cases, e.g. Constantinople/Petersburg activation, and to allow for extensibility in L2 downstream repositories, which have their own forks and progression but want to activate upstream forks as well.
Parameters
- Some protocol parameters can be set through the chain config. With the proposed system, parameters are
  handled by a global registry, and can be implemented across different packages. For example, the EIP-1559 configuration can be implemented in the eip1559 package, where the config is ultimately used.
- Parameters have a validation function which is called during config validation.
- There should also be a way to handle chain compatibility checks for each parameter. For example, we should check that blob schedule configuration is not modified in an incompatible way.
Config/Rules object
- The chain configuration should be immutable. Note it may not be possible to ensure this for parameters, since they can have an arbitrary Go type.
- 'Rules' are a way to resolve all active forks at a given block. The existing Rules implementation has some special cases related to the merge and Verkle. I want to remove these. Rules should just be a map[Fork]bool.

It's not great to call scheduleAtTime so many times. The function is much more expensive now since it has to establish the fork order every time. A later refactoring needs to turn it around to compute the order only once.

lightclient

This is looking really good, just catching up a bit on the changes. Saw a TODO for the TTD and BPOs for checking compatible - are there other major todo items?

lightclient · 2025-08-11T19:05:11Z

consensus/clique/config.go

+
+var ConfigParam = params.Define(params.T[Config]{
+	Name:     "clique",
+	Optional: true, // optional says


missing part of the comment here?

lightclient · 2025-08-11T19:53:33Z

params/config2.go

+	param      map[int]any
+}
+
+func NewConfig2(activations Activations, param ...ParamValue) *Config2 {


lightclient · 2025-08-11T19:56:31Z

params/config2.go

+	return ok
+}
+
+// SetActivations returns a new configuration with the given forks activated.


Suggested change

// SetActivations returns a new configuration with the given forks activated.

// SetActivations returns a new configuration with the given forks activations.

I think it should say "activations" since the way it currently reads is that that it will make the new config have the passed in forks be active.

This method is a little confusing to me in general though, it seems like it should set the forks for the current Config2 object (even overwriting the existing) but instead it returns a new object that has both the existing activations and the new activations.

lightclient · 2025-08-11T20:10:28Z

params/rules2.go

+func (cfg *Config2) Rules(blockNum uint64, blockTime uint64) Rules2 {
+	r := Rules2{
+		active: make(map[forks.Fork]bool, len(cfg.activation)),
+	}
+	return r
+}


Seems like this still needs to fill in the active map?

~Will probably be mostly supplanted by #32224, but this should do for now for devnet 3.~ Seems like #32224 is going to take some more time, so I have completed the implementation of eth_config here. It is quite a bit simpler to implement now that the config hashing was removed. --------- Co-authored-by: MariusVanDerWijden <m.vanderwijden@live.de> Co-authored-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com> Co-authored-by: rjl493456442 <garyrong0905@gmail.com>

~Will probably be mostly supplanted by ethereum#32224, but this should do for now for devnet 3.~ Seems like ethereum#32224 is going to take some more time, so I have completed the implementation of eth_config here. It is quite a bit simpler to implement now that the config hashing was removed. --------- Co-authored-by: MariusVanDerWijden <m.vanderwijden@live.de> Co-authored-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com> Co-authored-by: rjl493456442 <garyrong0905@gmail.com>

fjl requested review from gballet, rjl493456442 and zsfelfoldi as code owners July 16, 2025 13:03

fjl marked this pull request as draft July 16, 2025 13:04

lightclient mentioned this pull request Jul 18, 2025

internal/ethapi,params: add eth_config #32239

Merged

fjl force-pushed the config2 branch from d7586fc to ba518c3 Compare July 24, 2025 08:05

fjl added 24 commits August 4, 2025 16:56

params: WIP config2

8cc54f2

params: update

cab21e0

consensus/misc/eip4844: port to config2

9268b84

consensus/misc/eip1559: port to config2

d0a36a3

consensus/misc: update DAO fork for config2

46adeca

consensus/ethash: port to config2

3f128f6

consensus/beacon: port to config2

f79354d

params: add BigInt to TerminalTotalDifficulty

8725dec

consensus: update for config2

31b6360

params/forks: add After

74f62ce

params/presets: add TestChainConfig

e3725af

core/types: port to config2

fcf3b43

core/rawdb: port to config2

6b26791

params: new param system

b25e44a

params: move some code around

73710ff

params/presets: update for new system

c284949

params: add SetParam

ca4ba1f

consensus/misc/eip4844: update

2a6cf8b

consensus/misc/eip1559: update

d031689

consensus/misc: update

3e675b1

consensus/beacon: update

c1954d2

params: new fork & parameter registry

8da6d37

core/types: fix parameter access

57c395f

params: add validation tests and remove LatestFork

13d14f5

fjl added 8 commits August 4, 2025 16:56

params: add DependencyOrder function

cf8af42

params: fix param value decoding

336a2da

params: add tests for blobschedule validation

7b5c169

consensus/misc/eip4844: make it work

11ac2cc

It's not great to call scheduleAtTime so many times. The function is much more expensive now since it has to establish the fork order every time. A later refactoring needs to turn it around to compute the order only once.

params: add Defined

ee78ae4

core/vm: port to config2

0101ffe

params: add Rules2 (WIP)

1a63295

consensus/clique: partial port to config2

2157877

fjl force-pushed the config2 branch from 1d1173d to 2157877 Compare August 6, 2025 21:43

lightclient reviewed Aug 11, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

params: Config2 #32224

params: Config2 #32224

Uh oh!

fjl commented Jul 16, 2025 •

edited

Loading

Uh oh!

lightclient left a comment

Uh oh!

lightclient Aug 11, 2025

Uh oh!

lightclient Aug 11, 2025

Uh oh!

lightclient Aug 11, 2025

Uh oh!

lightclient Aug 11, 2025

Uh oh!

lightclient Aug 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	// SetActivations returns a new configuration with the given forks activated.
	// SetActivations returns a new configuration with the given forks activations.

params: Config2 #32224

Are you sure you want to change the base?

params: Config2 #32224

Uh oh!

Conversation

fjl commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lightclient left a comment

Choose a reason for hiding this comment

Uh oh!

lightclient Aug 11, 2025

Choose a reason for hiding this comment

Uh oh!

lightclient Aug 11, 2025

Choose a reason for hiding this comment

Uh oh!

lightclient Aug 11, 2025

Choose a reason for hiding this comment

Uh oh!

lightclient Aug 11, 2025

Choose a reason for hiding this comment

Uh oh!

lightclient Aug 11, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fjl commented Jul 16, 2025 •

edited

Loading